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DETAILED ACTION 

1. This application has been examined. Claims 1-30 presented for examination. 

Priority 

2. This application claims benefit of the provisional application 60/193,753 (03/3 1/2000). 

3. The effective filing date for the subject matter defined in the pending claims, which has 
support in Provisional Application No. 60/193,753 is 03/31/2000. Any new subject mater 
defined in the claims not previously disclosed in Provisional Application No. 60/193,753, is 
entitled to the effective filing date of 03/27/2001. 

Claim Rejections - 35 USC § 102 

4. The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the 
basis for the rejections under this section made in this Office action: 

A person shall be entitled to a patent unless - 

(e) the invention was described in a patent granted on an application for patent by another filed in the United 
States before the invention thereof by the applicant for patent, or on an international application by another who 
has fulfilled the requirements of paragraphs (1), (2), and (4) of section 371(c) of this title before the invention 
thereof by the applicant for patent. 

5. Claims 1-3, 9, 1 1-18, 24, and 26-30 rejected under 35 U.S.C. 102(e) as being anticipated 
by Shoroff et al. (U.S. Patent Number 6,381,602), hereinafter referred to as Shoroff 

6. Regarding claim 1, Shoroff disclosed a system for secure storage of information and 
controlled grant of access to said information to clients on a network, said system comprising: a 
server; a client computer coupled to said server via said network; a datastore configured to store 
said information; and an access controller coupled between said server and said datastore, 
wherein said access controller is adapted to function as an application server and provide a data 
representation of said information to said client by way of said server and said network as a 
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function of: (1) a request from said client sent by way of said network and said server; and (2) 
predetermined criteria; wherein said data representation is transient in said server (Abstract, 
Figures 2-4, column 3 lines 1 1-53, column 6 line 64-column 7 line 6, column 7 lines 15-24, 
column 9 lines 22-54). 

7. Regarding claim 2, Shoroff disclosed a system wherein said network includes the Internet 
and World Wide Web (column 6 lines 38-44). 

8. Regarding claim 3, Shoroff disclosed a system wherein said network includes a telephone 
network and said system includes a telephone coupled to said access controller via said telephone 
network [networking environments] (column 6 lines 31-44, line 64-14). Note: telephone network 
is well known in the networking environments. 

9. Regarding claim 9, Shoroff disclosed a system wherein said request from said client 
includes a client identification and an information identification (column 9 lines 22-54, column 
10 lines 9-31). 

1 0. Regarding claim 1 1 , Shoroff disclosed a system wherein said predetermined criteria may 
be different for different client types (Figure 4 sign 102', Figure 7 sign 120, 122, column 3 lines 
11-53, column 10 lines 9-31). 

1 1 . Regarding claim 12, Shoroff disclosed a system wherein said information includes a 
plurality of content items and said access controller provides to a graphical user interface of said 
client computer a client selectable content list, indicating content items for which said data 
representations can be provided to said client, wherein said client may generate said request by 
selecting a desired content item from said content list (Figures 3-5, column 3 lines 3 1-53, column 
9 lines 22-38, column 1 1 lines 29-43). 
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12. Regarding claim 13, Shoroff disclosed a system wherein a graphical user interface of a 
client computer includes mechanisms to facilitate said client generating said request by entering 
a URL, entering a content item identification, performing a text search, or manipulating a 
directory tree (column 3 lines 1 1-30, column 7 lines 44-56, column 9 lines 22-54). 

13. Regarding claim 14, Shoroff disclosed a system wherein said criteria include criteria for 
verifying that said client is entitled to be granted access to said information, said criteria for 
verifying including an identification of said user (Figure 7 sign 134, column 1 lines 39-49, 
column 9 lines 21-38). 

14. Regarding claim 1 5, Shoroff disclosed a system wherein said data representation is 
provided as a further function of history [cache] and profile information associated with said 
client (Figure 6 sign 108, Figure 7 sign 134, column llines 39-49, column 2 lines 56-58, column 
3 lines 12-30, lines 42-53, column 9 lines 21-38, column 10 lines 10-31, column 11 line 46- 
column 12 line 19). 

15. Regarding claims 16-18, 24, and 26-30, the method corresponds directly to the system of 
claims 1-2, 9, and 11-15, and thus these claims are rejected using the same rationale. 

16. Since all the limitations of the claimed invention were disclosed by Shoroff, claims 1-3, 
9, 1 1-18, 24, and 26-30 are rejected. 

17. Claims 1-2, 9-17, and 24-30 rejected under 35 U.S.C 102(e) as being anticipated by 
Mehring et al. (U.S. Patent Number 6,609,1 15), hereinafter referred to as Mehring. 

18. Regarding claim 1 , Mehring disclosed a system for secure storage of information and 
controlled grant of access to said information to clients on a network, said system comprising: a 
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server; a client computer coupled to said server via said network; a datastore configured to store 
said information; and an access controller coupled between said server and said datastore, 
wherein said access controller is adapted to function as an application server and provide a data 
representation of said information to said client by way of said server and said network as a 
function of: (1) a request from said client sent by way of said network and said server; and (2) 
predetermined criteria; wherein said data representation is transient in said server (Abstract, 
Figures 4-8, column 2 lines 31-42, column 2 line 61 -column 3 line 10, column 8 lines 9-37, 
column 9 lines 9-52, column 10 lines 4-31). 

19. Regarding claim 2, Mehring disclosed a system wherein said network includes the 
Internet and World Wide Web (Figures 4-5, column 3 lines 11-21, column 9 lines 9-17). 

20. Regarding claim 9, Mehring disclosed a system wherein said request from said client 
includes a client identification and an information identification (column 2 lines 31-42, column 3 
lines 1-10, column 8 lines 9-37, column 9 lines 28-52). 

21. Regarding claim 10, Mehring disclosed a system wherein said clients are typed and said 
data representation is provided to said client as a further function of a client type (column 13 
lines 39-61, column 14 lines 44-63). 

22. Regarding claim 11, Mehring disclosed a system wherein said predetermined criteria may 
be different for different client types (column 13 lines 38-61, column 14 lines 44-63). 

23. Regarding claim 12, Mehring disclosed a system wherein said information includes a 
plurality of content items and said access controller provides to a graphical user interface of said 
client computer a client selectable content list, indicating content items for which said data 
representations can be provided to said client, wherein said client may generate said request by 



Application/Control Number: 09/81 8, 1 30 Page 6 

Art Unit: 2144 

selecting a desired content item from said content list (Figures 6 and 8, column 7 lines 1-28, 
column 9 lines 8-17, column 10 lines 4-31). 

24. Regarding claim 13, Mehring disclosed a system wherein a graphical user interface of a 
client computer includes mechanisms to facilitate said client generating said request by entering 
a URL, entering a content item identification, performing a text search, or manipulating a 
directory tree (Figures 6 and 8, column 9 lines 9-17). 

25. Regarding claim 14, Mehring disclosed a system wherein said criteria include criteria for 
verifying that said client is entitled to be granted access to said information, said criteria for 
verifying including an identification of said user (Figures 6 and 8, column 2 lines 31-42, column 
8 lines 9-37). 

26. Regarding claim 1 5, Mehring disclosed a system wherein said data representation is 
provided as a further function of history and profile information associated with said client 
(column 11 lines 1-24). 

27. Regarding claims 16-17 and 24-30, the method corresponds directly to the system of 
claims 1-2 and 9-15, and thus these claims are rejected using the same rationale. 

28. Since all the limitations of the claimed invention were disclosed by Mehring, claims 1-2 
and 9-17, 24-30 are rejected. 

Claim Rejections - 35 USC § 103 

29. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made. 
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30. Claims 4-8, 10, 19-23, and 25 are rejected under 35 U.S.G 103(a) as being unpatentable 
over Shoroff et al. (U.S. Patent Number 6,381,602), hereinafter referred to as Shoroff, as applied 
to above in view of Ballard (U.S Patent Number 6,182,050). 

3 1 . Regarding claim 4, Shoroff disclosed a system for secure storage of information and 
controlled grant of access to said information to clients on a network, said system comprising: a 
server; a client computer coupled to said server via said network; a datastore configured to store 
said information; and an access controller coupled between said server and said datastore, 
wherein said access controller is adapted to function as an application server and provide a data 
representation of said information to said client by way of said server and said network as a 
function of: (1) a request from said client sent by way of said network and said server; and (2) 
predetermined criteria; wherein said data representation is transient in said server (Abstract, 
Figures 2-4, column 3 lines 1 1-53, column 6 line 64-column 7 line 6, column 7 lines 15-24, 
column 9 lines 22-54). 

32. Shoroff taught the invention substantially as claimed. However, Shoroff did not expressly 
teach a system wherein said predetermined criteria define a time window for which said 
information is available for access. 

33. Shoroff suggested exploration of art and/or provided a reason to modify the system with 
the time window access feature (column 12 lines 1-19). 

34. Ballard disclosed a system wherein said predetermined criteria define a time window for 
which said information is available for access. 

35. It would have been obvious to one of ordinary skill in the art at the time of the invention 
was made to modify the system of Shoroff with the teachings of Ballard to include the time 
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window access feature in order to monitor the access information (Ballard, column 7 lines 36-55) 
since it is beneficial to allow the distribution system to be automated over a public networks 
(Ballard, column 8 lines 7-21). In addition, if the information is available for access relates to 
broadcast or advertisement, the owner of the information might only want to pay to have their 
information distributed to a requisite number of end users within a specific period of time 
(Ballard, column 10 lines 54-67). 

36. Regarding claim 5, Ballard disclosed a system wherein said criteria includes a start date, 
wherein said start date defines when said information is made available for access (column 7 
lines 41-49, column 10 lines 54-67, column 17 lines 36-61, column 18 lines 33-50). 

37. Regarding claim 6, Ballard disclosed a system wherein said criteria includes a period of 
duration of access, wherein said period of duration of access commences upon said information 
being accessed by said client (column 7 lines 41-49, column 10 lines 54-67, column 17 lines 36- 
61, column 18 lines 33-50). 

38. Regarding claim 7, Ballard disclosed a system wherein said criteria includes an end date, 
wherein said end date defines when said information ceases to be available for access (column 7 
lines 41-49, column 10 lines 54-67, column 17 lines 36-61, column 18 lines 33-50). 

39. Regarding claim 8, Ballard disclosed a system wherein said criteria includes a start date 
and a start time, wherein said start date and start time define when said information is made 
available for access, and further includes an end date and an end time, wherein said end date and 
end time define when said information ceases to be available for access (column 7 lines 41-49, 
column 10 lines 54-67, column 17 lines 36-61, column 18 lines 33-50). 
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40. Regarding claim 10, Ballard disclosed a system wherein said clients are typed and said 
data representation is provided to said client as a further function of a client type (column 9 lines 
22-67). 

41. Regarding claims 19-23, and 25, the method corresponds directly to the system of claims 
4-8, and 10, and thus these claims are rejected using the same rationale. 

42. Since all the limitations of the claimed invention were disclosed by the combination of 
Shoroff and Ballard, claims 4-8, 10, 19-23, and 25 are rejected. 

Conclusion 

43. The prior art made of record and not relied upon is considered pertinent to applicant's 
disclosure. Refer to the enclosed PTO-892 for details. 

44. Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Tam (Jenny) Phan whose telephone number is (703) 305-4665. 
The examiner can normally be reached on M-F 9:00-5:00. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, William Cuchlinski can be reached on 703-308-3873. The fax phone number for the 
organization where this application or proceeding is assigned is 703-872-9306. 

Any inquiry of a general nature or relating to the status of this application or proceeding 
should be directed to the receptionist whose telephone number is (703) 305-3900. 

Information regarding the status of an application may be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published applications 
may be obtained from either Private PAIR or Public PAIR. Status information for unpublished 
applications is available through Private PAIR only. For more information about the PAIR 
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system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR 
system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). 



William Cuchlinski 
SPE 

Art Unit 2144 
703-308-3873 



tp 

July 6, 2004 



WILLIAM A. CUCHLINSKI, JR. 
SUPERVISORY PATENT EXAMINER 
TECHNOLOGY CENTER 3600 
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ABSTRACT 

In this paper we propose a Dynamic Access Control Model (DACM) 
to meet the access control requirements of an environment thai 
frequently change and adjust their user access privilege and/or target 
object confidential level. 

For DACM, wc use object-orient technique in describing the whole 
model and also in implementing its access control mechanism called 
Dynamic Access Control System (DACS). For DACS, there are three 
server object modules within it to satisfy the request of access 
authorization check Issued from any Client Object (CO) module. The 
three server objects of DACS are: (1) User_Security_Manager (USM) 
which dynamically maintains user privilege information stored in a 
persistent table called User_Security_Tablc (UST); (2) 
Taiget_Ob)ect_>fanager (TOM) which dynamically maintains the access 
authorization rules stored in the persistent tabic called 
Taiget.Objectjrable (TOT) for every target object; and (3) 
Acoess.Contro)_Manager (ACM) which is a higher level object module 
upon USM and TOM and performs a rule-based access authorization 
checking procedure for the Client Object. Also, two assistant tools 
called User Privilege List and Target Object Authorization List are 
provided as visual aids for the security controller of DACM to implement 
their access control policy. 

A real case similar to DACM has been implemented in the 
Administration Information System of Central Police University, the 
performance shown in this case Is quite good in the viewpoints of both 
end user and system developers/maintainers. Wc find thai DACM 
technique can really be used co cope with the dynamically changing 
environment. 

Finally, a discussion was made about several open questions and 
possible solutions for those DACM implementocs. Since Environments 
are different for each DACM tm pic mentor, so that there are really some 
thing different in the consideration. 



KEYWORD: ACCESS CONTROL, OBJECT-ORIENTED, SECURITY. 
RULE-BASED, ODMS 

* instructor of department of information management. Central Police 
University 

♦* professor and chief of computer center, Central Police University 



may need to be changed because of his promotion or transferring 
department In a organization, on the other hand, the access authorization 
rules of a target object in an information system[2, 4, 12, 1 3] may change 
because of some real world situation. 

To satisfy the access control requirements of information system to 
cope with the dynamically changing environment, we propose a new 
access control technique called Dynamic Access Control Model (DACM) 
which can be implemented in an object-oriented software system to 
provide a role-based access control mechanism. 

II. DYNAMIC ACCESSS CONTROL MODEL ( DACM ) 

\, DACM Modeling 

In DACM environment, we suppose that there is an object-oriented 
(00) information system with a security controller who centralized 
performs all the information access control tasks. Figure 1 describes the 
whole system environment of DACM, where Dynamic Access Control 
System (DACS) provides an access control mechanism for all the object- 
oriented information system, and the Object Database Management 
System (ODMS) manages all the data and methods of object modules of 
the information system. 

1 , 

{ 

| Ofafwd Orir^d fo fmmitton Sy<^>rw _| 



ODMS 

X 



Data ft Methods 




Figure 1. Dynamic access control model 



I. INTRODUCTION 

Access Control In information system refers to use a mechanism to 
protect shared Information or other resources among users via a 
mechanismlU. 14). The access control mechanism can enforce the 
policies governing resource use. An access control model is a 
description of the whole protected system including the access 
control mechanism. Traditionally, there are several ways to describe an 
access control model, for example, access matrix, access list, capability 
list* protection domain, access domain, ...etc.; also there are a lot of 
access control technique developed, for example, lock-key mechanism, 
capability-based system, ring structure system, user classification by 
group, user classification by privilege level, ... etc[l, 2, 3, 4, 5, 6, 7, 8, 9, 
10. 14). 

Since real world are so dynamic and changing that access control 
policies are changed frequently. For example, a user access privilege 



2. Components in DACS 

Figure 2 is a detail look of Dynamic Access Control System (DACS), 
where we can see that as soon as an external object (called client object. 
CO) issues a request for an access authorization check by calling 
Acccss_ControLManager (ACM) (like a server object), the ACM 
Immediately perform a rule-based access authorization checking 
procedure according to the message passed from User_&ecurity_Managcr 
(USM) and Target_Ob]ect_M anager (TOM), and then passes the message 
of checking result back to the Client Object (CO). The client object (CO) 
Is a general term for any object which is external the DACS and wishes 
to has an access protection function surround it. 
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Figure 2. Internal objects and tables In D ACS 



3. Tables and Objects in DACS 
3.1 Tables 

3.1.1. User_SecurityJToble ( UST ) 



Access_Conirol_Manager separately. The following is a description of 
those data, methods (i.e. procedures in C++) and/or algorithms for each 
object used in DACS. 

3.2.1. User_Security_Manager ( USM ) 

. Data 

has several transient data used to map with those persistent data stored 
in UST. 

. Methods 

• get_privilege(uid-a, gcode_a, plcvel.a, rcode_a) 
. function - to rein eve user group code and privilege level 
information from UST for ACM. 

. parameter - 

. uid_a • inputted user id passed from ACM 
. gcode.u - returned group code retrieved from UST 
. plevel_a * returned privilege level retrieved from UST 
. rcode_a - relumed code, 0, OK 

I, INVALID USER-ID 



- check_password(uid_a, pwd.a, rcode.a) 

. function - to perform login user password check for the login 
handling object. 

- ( other methods ) 

. function - to provide insertion, modification, deletion and inquiry 
function to maintain Uscr_Security_Table (UST). 

3.2.2. Target jObjectJtfanager ( TOM ) 

. Data 

has several iransienl data used to map with those persistent data stored 
in TOT. 



It is a persistent table[13] storing all the users' access privilege 
information, and that (here is one entry for each user. The attributes In 
the table are: 



. Methods 



ATTRIBUTES 

.user, id 
.user name/title 
.group.code 
.privitegejevel 



3.1.2. Target.Object.Table ( TOT > 



REMARK 
an Indexed key 

blank for all 
value is 0-9 



- get_flrst(tld_h t uid_b, gcode_b, plevel J>, rcodeJ>) 
. function 



.parameter 
.Ud_b 
uid_b 
.geodej) 
. plevel.b 
. rcode_b 



to retrieve the first access authorization rule 
ntry from table TOT for the input target object id. 

inputted target object Id passed from ACM 
returned user id retrieved from TOT 
returned group code retrieved from TOT 
returned privilege level retrieved from TOT 
returned code. 0: OK 

I: NOT FOUND 



It is a persistent table storing all the access authorization rules for 
target objects, and that (here can be one or multiple entries (rules) for 
each target object. If there is no entry in this tablwe for a specific target 
object, it means that this target object cun be accessed by all of the users 
In the system. 



ATTRIBUTES REMARK 
. target _objccUd an indexed key 

■ t arget_ohject_name/t i tl e 
.authorized.userjd blank for all 

. authorized _group_codc blank for all 
. minimal .accessible. value is 0-9 
privilegejevel 

3.2. Objects 

We wilt use C++ like semantic here to describe all the objects, and 
suppose dial USM. TOM and ACM represent one of the objects of 
classes User_SecurUy_Manager, ar get _ Object .Manager and 



- gef_nexl(uid_b, gcode_b, plevcLb. ra*te_b) 

. function - to retrieve the nexi access authorization rule entry 
from table TOT for the input target ohject id. 

- ( other methods ) 

. function - to provide insertion, modification, deletion and 

inquiry function to maintain Target -Object Table 
(TOT). 

3.2.3. Access , ControlJManager ( ACM ) 
. Data 

has several transient data used to perform the rule-based access 
authorization checking procedure. 

. Methods 

• access.controKuid, lid, rcodc) 
. function - to provide a rule-based algorithm to make the decision 
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uf access authorization according to the input 
parameters and the message from USM and TOM. 

. parameter - 

. ud_b - inputted target nbject id from the client object 
. uid_b - inputted user id bum the client object 
. rcode.b - returned code. 0: ACCESS ACCEPTABIJS 
1: ACCESS DENIED 
2: IN VALID USER-ID 

, Algorithm for frrtcedure Access .Control ( in C++ sementlc ) 

uid and ud is passed from the client object ; 

CLASS user^security.nunager ; // declare a class 
CLASS target_object_manager ; 

PROCEDURE access-control ( uid. tid. rcode ) 
I 

user_security_manager usm ; // usm is an object of 

ser_secu riiy_m anagcr 
iarget.object_munager torn ; // torn is an object of 

targct_object_nianager 
usin.gct_nrivilcgc(utd. gcodc_a . // get user privilege information 

pIcveLa, rcode.a ) ; // from table UST. 
IE ( rcode _a !« 0 ) // test whether the return code is OK ? 

rcode » 2 ; 

ELSE // the user id is valid. 

I 



tom.gei Jir>t(tid, uid_t> , gcode_b, // get the fmi entry from tabic TOT 

plevet_b. rcode _b ) ; // for the input target object -tid. 
IF ( rcode.b !* 0 ) //are there any rules for tid_b 7 

rcode m o ; //all users can access this target object. 

ELSE 
f 

rcode « I ; 

WHILE < rcode.b »» 0 uitd rcode *=!)// loop until cod of entry 
4 or access is authorized. 

IF <uid_b Knuc blank) // is ihis access autaoriation for a 
specific user or a class of users ? 

IF ( uid_o m uid_b ) 

rcode » U ; // access authorized. 

FASH 

ELSE 

IF (gcode.ii is blutifc OR // IK user luis uo group code coasi- 
gcode.b isbLiitk ) // ruint OK IF' target object bus ao 
li group code constraint, THEN ... 
IF ( plcvel.a >» plevel.h ) // is the user privilege level 
rcode - 0 , // high enough ? 

ei^e 

ELSE 

IF ( gaxle.u « gai^e.b ) 

IE ( plevelji >=> plevel.b } 
rcode »0; 

tom.gei_nexl{tid, u«Ln , gcode.b, // get the neit entry from 
plevel.b, rcode.b ): // table TOT for the input 
// target object. 



Ill Tools for DACM 

Besides traditional access matrix, capability list and access list, two 
other lists arc proposed as visual aids for the security controller of 
DACM to facilitate his routine job. 

1. User Security List 

It is generated from user security table and sorted by USER ID, the 
format and illustration is shown in Table 1. For example in Tabic 1, 
USER-01 is authorized to access those objects which can be used by 
group GOO] and required minimal privilege level is higher than 4, 
however, USER-04 is authorized to access all the objects with only 
required minimal privilege level not higher than 6. 

2. Target Object Authorization List 

It is generated from target object table and sorted by TARGET 
OBJECT ID, the formal and illustration is shown in Table 2. For 
example in Table 2, entry 1 indicates that USER-03 is authorized to 
access OBJ-01. Also, entry 2 indicates that those uscr(s) with group 
code G001 or blank and privilege level not lower than 5 are 
authorized to access object OBJ-01. And entry 6 represents that all 
those users with privilege level not lower than 6 are authorized to 
access object ODJ-06. 

According to the illustration in Table I and Tabic 2, we can get an 
matrix as follows, note that OUJ-07 is a target object with no rule 
in the TargecObjcct_Table, so it means that OBJ-07 can be accessed by 
all of the users in the system 



IV. Example of DACM 

A real case similar lo DACM has been implemented in the 
Administration Information System of Central Police University. The 
r^rforrnance is quite good in the viewpoints of both end users and system 
developers. To ihc security controller's viewpoints, it is convenient to 
manage the dynamic changing environment by tuning the user security 
table (UST) when a new user is added or when the access privilege 
domain of an existed user should be modified, or tuning (he target object 
table (TOT) when several access protection rules should be put on an 
object or when the confidential level of an existed object needs . to be 
upgraded or downgraded to meet the real world situation. Also, the 
routine access control job of the DACM security controller is facilitated 
via using convenient interactive end-user interface to maintain UST and 
TOT, and via using flexible visual aids, i.e.,user security list, target 
object authorization list, capability list, access list and/or access matrix. 

On the other hand, to the system developers and maintainors 
viewpoints, DACM technique is quite simple and is clear to implement 
into the information system. And also, since we are using the object- 
oriented technique in DACM, so that the Dynamic Access Control 
System (DACS) can be treated as an access control server, whenever a 
new system module is incorporated into the existed information system, 
it can ulso share the DACS protection function only by embedding the 
calling acoess_control.raanager (ACM) instruction in it as playing a role 
of the Client Object (CO) to the ACM. 



pass the return code (rcode) back to the client object ; 



Table 1. User Security Ust 



SEQ 






(USER'S) 


(USERS) 




USER ID 


USER TITLE 


GROUP 


PRIVILEGE 


No. 






CODE 


LEVEL 




USER-01 


Peter Bush 


G0001 


4 


2 


USER-02 


Robert Smith 


G0002 


11 


3 


USER-03 


Mary Rogers 


G0003 


S 


4 


USER-04 


Beaver Ken 


(blank) 


6 


5 


USER-05 


Sophia Clinton 


(blank) 


9 
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Table 2. Target Object Authorization List 



SEQ 


TARGET 


AUTHORIZED 


AUTHORIZED 


MINIMAL 




OBJECT ID 


USER ID 


GROUP CODE 


PRIVILEGE 


No. 








LEVEL 


1 


OBJ-01 


USER-03 


n/a 


n/a 


2 


OBJ-02 


(blank) 


G001 


5 


3 


OBJ-03 


(blank) 


G001 


4 


4 


OBJ-04 


(blank) 


G001 


6 


5 


OBJ-05 


(blank) 


G003 


4 


6 


OBJ-06 


(blank) 


(blonkO 


3 


7 




(blank) 


(blank) 


7 



* n/a * not available 



Table 3. Access Matrix 



1 | OBJ-01 


OBJ-02 


OBJ-03 


OBJ-04 


OBJ-05 


OBJ-06 


OBJ-07 


1 ifriaTgiTl s^FjM 


yes 


no 


no 


_ yes 


no 


yes 




yes 


yes 


no 


yes 


yes 


yes 




no 


no 


yes 


yes 


no 


yes 




yes 


yes 


yes 


yes 


no 


yes 




yes 


yes 


yes 


-J* 


yes 





V. Discussion 



1. We can see from the real case in part IV that DACM technique Is 
actually workable and can provide a quite good performance both in 
the viewpoints of end users, system developers and system 
maintainers. 

X Since this paper is a sirapliOed description of DACM. so there are 
some areas need to be modified or taking into consideration for 
practical Implementation viewpoints 

(1) . Group code can be multiple to meet the requirements of a multi- 

level organ! zatioa For example, soraeon can only access all the 
objects which belongs to those different sub-groups of a higher 
level group 

(2) . How to keep the user-id after end user logged in, that is, how can 

we let ACM to know the login user Id ? Foe example, we can 
keep the user Id In a transient or persistent table is one of the 
way, or transfer it object-by-object is another way. 

(3) . How to naming the target object id's ? 

For example, the target object id may represent a function, a 
tabic, or any other resources which needs to be protected, 

(4) . What if user need to classify different kind of access right for a 

specific target object 7 For example, read, write, modify, delete 
and/or execute ... etc The possible solution could be : (1). naming 
different id's for the different kind of access right of a specific 
target object. (U). add some additional attribute/field into 
targecobjecctable (TOT) to represent the availability of the 
different kind of access right 

(5) . Convenient user interfaces for security controllers ure required. 

For example, (i). interfaces to maintain userjsecurity.table and 
target.obJect_table. (ii). interfaces to browse or print user 
security list, target object authorization list, capability list, access 
list and access matrix. 



3. The similar concept of DACM seems can be implemented in an Object 
Database Management System as a common access control tool. 
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Abstract 

Although there are several choices of policies for pro- 
tection of information, access control models have been 
developed for a fixed set pre-defined access control poli- 
cies that are then built into the corresponding access 
conttvl mechanisms. This becomes a problem, however, 
if the access control requirements of an application are 
different from the policies built into a mechanism. In 
most cases, the only solution ts to enforce the require- 
ments as part of the application code, but this makes 
verification, modification, and adequate enforcement of 
these policies impossible. In this paper f we propose 
a flexible authorization mechanism that can support 
different security policies. The mechanism enforces a 
general authorization model onto which multiple access 
control policies can be mapped. The model permits neg- 
ative and positive authorizations, authorizations that 
must be strongly obeyed and authorizations that allow 
for exceptions, and enforces ownership together with 
delegation of administrative privileges. 



1 Introduction 

Recent years have witnessed considerable work on 
access control models and related mechanisms for 
databases [8]. Most of this work deals with relational 

*The work of S. Jajodia was partially funded by MITRE 
Sponsored Research, project 91850. He is also with the Center 
for Secure Information Systems and Department of Information 
and Software Systems Engineering, George Mason University, 
Fairfax, VA 22030-4444 



databases systems, although recently advances have 
been reported in the areas of object-oriented database 
systems [3] and deductive databases [6]. Despite this 
large research effort, current access control models and 
mechanisms are not flexible enough to meet the access 
control requirements of modern application environ- 
ments [10]. This lack of flexibility exists because each 
model has been developed for a number of pre-defined 
access control policies; these policies are built into the 
corresponding access control mechanism and, there- 
fore, cannot be changed. The majority of the mod- 
els are based on a closed world policy, which permits 
specification of only positive authorizations and allows 
only accesses explicitly authorized. In contrast, very 
few models are based on the open world policy which 
permits the specifications of only negative authoriza- 
tions, and all accesses not explicitly denied are allowed. 
Recent authorization models enforcing a closed policy 
also allow users to specify negative authorizations and 
resolve conflicts according to some predefined rules [5]. 

A problem arises when the access control require- 
ments of an application differ from the policies built 
into the mechanism at hand. Enforcing the applica- 
tion policy becomes very difficult and, i/i most cases, 
the only solution is to implement the policy as part of 
the application code. This solution, however, makes 
the tasks of verification, modification, and adequate 
enforcement of the the policy difficult. 

A promising solution to this problem is represented 
by the multipolicy access control systems. The develop- 
ment of a multipolicy system is a challenging area that 
is still at an early stage. It poses several challenges, 
including (1) what is the proper spectrum of policies 



0-6186-7417-2/96 $5.00 © 1996 IKRR 



94 



with respect to which the users must be able to tailor 
the system, (2) how to decouple the policy from the en- 
forcement mechanism, (3) what is the efficiency of the 
mechanism, and (4) whether conflicting policies can be 
defined for the same data objects and, if so, how to 
resolve such conflicts. 

In this paper, we take a first step toward the investi- 
gation of these issues. We present a multipolicy system 
that can support a number of discretionary access con- 
trol policies for relational database systems, including 
the traditional closed and open policies, closed policy 
with negative authorizations and the application of the 
denials-take-precedence principle (to resolve conflicts 
among authorizations), and the closed policy with neg- 
ative authorizations and the enforcement of the most 
specific authorization takes precedence principle. 

The architecture of the system has two components: 
an access control mechanism and a mediator. The au- 
thorization model enforced by the mechanism is actu- 
ally based on the closed policy with negative autho- 
rizations where conflicting authorizations are resolved 
by application of the most specific authorization takes 
precedence principle. The mediator, which is an inter- 
face between users and the access control mechanism, 
supports other policies by using only some of the fea- 
tures of the authorization model. An important feature 
of the system architecture is that it has been designed 
to separate the policy specification component from the 
authorization and enforcement components of the sys- 
tem. Here, we focus on the authorization model and 
show how its flexibility can be exploited to support a 
number of different policies within the same database, 

The remainder of this paper is organized as follows. 
We begin in Section 2 by giving the architecture of 
the system. Section 3 illustrates the basic elements of 
the authorization model. Section 4 discusses the ac- 
cess control mechanism, which shows how the system 
determines whether to grant or reject access requests. 
Section 5 discusses administration of authorizations. 
Sections 6 and 7 discuss the consistency of the autho- 
rization state and the resolution of conflicts among au- 
thorizations, respectively. Section 8 illustrates how the 
mediator and the model proposed in this paper are used 
to support different policies. Section 9 discusses related 
work. Finally, Section 10 presents the conclusions. 

2 Architecture of the multipolicy ac- 
cess control system 

The goal of our system is to provide a flexible frame- 
work that can support different protection policies. 
Upon creation of each table, its owner can specify the 
type of protection policy he or she wishes to apply to 
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Figure 1. Multipolicy access control system 
architecture 



that specific table. What is interesting is that it is pos- 
sible to protect different tables in the same database 
according to different policies. 

The architecture of our system is illustrated in Fig- 
ure t . The two major components of the architecture 
are i) the access control mechanism implementing the 
authorization. model and ii) a mediator [24], which is an 
interface between users and the access control mecha- 
nism. The model enforced by the access control mecha- 
nism is a general model able to support different protec- 
tion policies (see Section 8). It is a task of the mediator 
to map the different protection policies and protection 
requirements onto a set of authorizations in the general 
model implemented by the mechanism. The mediator 
also filters every grant request to ensure that autho- 
rizations granted obey the specific policy for the ob- 
ject. For example, the mediator must ensure that no 
positive authorization can be specified on an object on 
which an open policy is to be applied. 

The authorization model that is implemented by the 
access control mechanism is described in the nexl. sec- 
tion. It is built on the concept of strong and weak au- 
thorizations first proposed in the Orion authorization 
model [19]. However, our model differs considerably 
from Orion not only in terms of the semantics associ- 
ated with negative authorizations, but also in the way 
conflicts between authorizations are resolved. More- 
over, unlike Orion, our model supports ownership to- 
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gether with decentralized administration of authoriza- 
tions. At the same time, administrative privileges can 
also be restricted iu our model so that owners retain 
control over their tables. 

3 The authorization model 

In this section, we introduce our authorization 
model. We start by giving basic notations and defi- 
nitions and then discuss how negative and positive au- 
thorizations coexist in our model. 

3.1 Notatioas and definitions 

Subjects of authorizations can be either users or 
groups. Members of groups can be users as well as 
other groups. Hence, membership of a subject 3 in a 
group Gjt can be either direct or indirect. The mem- 
bership is direct, written s €1 Git, if the subject is 
defined as a member of G*. The membership is indi- 
rect, written s 6„ Gjt.n > 1» if there exists a sequence 
of subjects (si, . . . , such that s\ = s, s n+ i = G*, 

and $i €1 < * < Sequence {si t . . . , s n +\) is 

called a membership path of s to G*, written mp(s t Gjt). 
We use €0 to indicate equality, i.e., for each subject «, 
s €0 J- 1 In the following discussion, we use the term 
membership to refer to either direct or indirect mem- 
bership. We will explicitly use the terms direct mem- 
bership or indirect membership when a distinction is 
needed, A subject can belong to a group in many ways, 
cither as a direct or as an indirect member. We use 
MP(s,Gt) to denote the set of all membership paths 
from user s to group G*. 

The membership relationship between subjects can 
be represented by a graph, called the group membership 
graph, in which nodes represent, subjects and an edge 
from node j!< to node Sj indicates that s, is a direct 
member of 8j (i.e., $i 6i sj). We require that the 
group membership graph be a directed acyclic graph. 

Authorizations specify the privileges that subjects 
are authorized or denied on objects. In our model, a 
grantor has the option of specifying whether the au- 
thorization (positive or negative) he is granting can be 
overridden or not. To support this functionality, we 
introduce, as in [19], the notion of strong and weak au- 
thorizations. The basic idea behind this approach is 
that strong authorizations cannot be overridden, while 
weak authorizations can be overridden, according to 
specified rules, 2 by other strong or weak authorizations. 

1 We continue to use the symbol € to denote the membership 
of on element in a set. 

2 These rulea are given in the next subsection. 




Figure 2. An authorization state 

Let U denote the users in the system, G the set 
of groups, P the set of privileges (i.e., select, insert, 
delete, and update), T the set of tables, and S = f/UG 
the set of all subjects (either users or groups) in the 
system. Authorizations are defined as follows. 

Definition 1 (Authorization) An authorization is 
a 6-tupie of the form (s^iPtit, g,at), with s € S, 
pe P, pie {+, -}, t € T, g € U, and at G {weak, 
strong}. 

Authorization (s,p,jrf,*, g } at) states that s has been 
granted (denied if p/ ="-") privilege p on table t by 
user g. If at = "weak" the authorization admits excep- 
tions. For example, tuple (G2, select, — , T, A t weak) 
indicates that members of group G2 cannot select tu- 
ples from table T, and this authorization, which admits 
exceptions, was granted by user A. 

Given an authorization a, we use the notation 
s(a) ) p(a) ) pt(a) i t(a) t g(a) i at(a) to denote the subject, 
the privilege, the privilege type, the table, the grantor, 
and the authorization type in a, respectively. For ex- 
ample, s(a) is the subject in authorization o. 

The set of authorizations that are present at a given 
time represents the authorization state, denoted by AS. 
In the following discussion, we graphically represent 
the authorization state by associating authorizations 
with subjects in the group membership graph. We in- 
dicate that subject s ( - owns a positive authorization 
for privilege p on table t by associating a pair (p, t) 
with node j,- in the group membership graph. Anal- 
ogously, pair {-»/?, t) associated with node 64 indicates 
that Si owns a negative authorization for p on t, To 
distinguish between strong and weak authorizations, 
we write strong authorizations in bold type. An exam- 
ple of authorization state is illustrated in Figure 2. 

A user is allowed to exercise, beside his own autho- 
rizations, all the authorizations of any of the groups to 
which he belongs. We do not restrict the user to the 
use of the authorizations of only one group at a time. 
A user has all the privileges that are in the union of all 
his personal authorizations and the authorizations of 
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all the groups to which he belongs. Note that this ap- 
proach follows the approach for group management of 
most existing database management systems (DBMSs) 
like, for example, System R [25, 13] and Orion [19]. 
This approach accords with the concept of user group 
as opposed to the concept of role (where a user may be 
constrained to operate with the privileges of a single 
role at a time) [1, 20]. 

Complications arise when a user is both authorized 
and denied, either directly or indirectly (i.e., through 
a group), for a privilege on a table. In the following 
discussion, we give our approach for dealing with the 
simultaneous presence of positive and negative autho- 
rizations. 

3.2 Overriding authorizations 

When dealing with authorizations admitting excep- 
tions, an important issue is to devise proper overriding 
rules. Such rules establish those circumstances under 
which exceptions can be issued against a weak autho- 
rization. In our model, strong authorizations always 
override weak authorizations. The overriding rule be- 
tween weak authorizations is based on the concept of 
more specific authorization. Authorizations given to a 
member of a group are always more specific than the 
authorizations given to the group (with respect to the 
member). The overriding rule between authorizations 
is formalized as follows: 

Definition 2 (Overriding authorization) An au- 
thorization a.i overrides a weak authorization aj, with 
p(ai) = p(a i ),t(ai) = t(aj),pt{ai) ± with 
respect to subject s (written a; >, aj), with s € n 
«(«*)»* € m s i a j)> f or some n t m > 0, iff any of the 
following conditions is satisfied: 

♦ at(ai) = strong 

♦ at(ai) = weak, s = «(«*), s s(oj) 

♦ at(ai) = weak, s(a,) €( ts(fij)J > 1, and Vmp € 
MP(s, s(aj)) : either s(a t ) 6 mp, or 3s f 6 5, a' € 
AS, /3k > Qsuch that s f £ £ s(a ; ),s' £ k 
s(ai),a' t> 8 * aj. 

Definition 2 states that: 

♦ a strong authorization a» overrides a weak autho- 
rization aj , with same privilege and table, but dif- 
ferent privilege type, with respect to any subject 
which belongs to both s(a,*) and s(a ; ); 

♦ a weak authorization a< overrides a weak autho- 
rization aj , with same privilege and tabic, but dif- 
ferent privilege type, with respect to subject *(<!,■), 
if s(ai) belongs to s(oj); 



• a weak authorization a; overrides a weak autho- 
rization aj with same privilege and table, but 
different privilege type, and with s(af) that be- 
longs to s(aj)i with respect to subject a, which 
belongs to both s(a;) and s(aj) if and only if ev- 
ery membership path from 5 to s(flj) either con- 
tains s(di) or contains a subject s', not belonging 
to s(cu), with respect to which authorization a ; - is 
overridden. 3 

Notice that the definition of overriding authoriza- 
tions is given in terms of a subject since the outcome 
of the override operation may be different depending 
on the subject. Even if authorization a» overrides au- 
thorization aj with respect to a group G, it docs not 
follow that (ii will override aj with respect to every 
subject s which is a member of G. 

Example 1 Consider the authorization state illus- 
trated in Figure 2. The negative weak authorization 
(-»sel,T) specified for G\ is overridden by (i) strong 
positive authorization (se^T) specified for G$ with re- 
spect to user D, (ii) positive weak authorization (sel,T) 
specified for G2 with respect to group Gi as well as user 
A, and (iii) the positive weak authorization (sel.T) 
specified for G3 with respect to group G3 as well as 
users A and B. Notice that it is not overridden by the 
latter authorization with respect to user C, This is be- 
cause C belongs to G\ also due to its membership of 
G 4 , for which no authorization is specified. □ 

3,3 Conflicts among authorizations 

Two contrasting authorizations such that neither 
one of them overrides the other are said to be in con- 
flict. This is formalized as follows: 

Definition 3 (Conflicting authorizations) Two 

authorizations Oj and aj conflict with respect to subject 
s (written a,- o, aj), with s 6n s(a t ),s 6 m s(aj) t for 

some n,m > 0 iffpi^i) = K a j)>*(°i) = *( a >)»P*( fl 0 9* 
pt(aj) and neither a,* t>, a,- nor aj fc>, a,*. 

For instance, with reference to the authorization 
state illustrated in Figure 2, the authorizations of G\ 
and G3 conflict over user C. Note that the concept 
of conflicting authorization is also defined with respect 
to a subject since it is being defined in terms of the 
overriding relationship. 

According to Definition 2, since a strong authoriza- 
tion always overrides a weak authorization (with re- 
spect to a given subject), no conflicts can exist be- 
tween a strong authorization and a weak authorization. 

3 Authorisation a 1 and the authorization specified for a' "col- 
laborate" in overriding aj. 
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Therefore, conflicts may exist only between two strong 
authorizations or between two weak authorizations. 

If two strong authorizations exist which conflict with 
respect to a given subject, we say that the authoriza- 
tion state is inconsistent It is considered consistent 
otherwise. This is formalized as follows: 



Definition 4 (Consistency of authorization state) 
The authorization state is consistent iff strong autho- 
rizations do not conflict (with respect to any subject). 

In onr model, the simultaneous presence of conflict- 
ing strong authorizations is not permitted. This is be- 
cause we wish to ensure that the semantics of strong 
authorizations will always be respected. Then, we re- 
quire the following invariant to hold. 

Invariant 1 The authorization state is consistent. 

It is the task of the access control system to en- 
sure the consistency of the authorization state. Section 
6 discusses how the system operates to ensure consis- 
tency of the authorization state. 

In our model, we accept the simultaneous presence 
of two conflicting weak authorizations. This choice is 
justified by the following facts: i) requiring complete 
absence of conflicts may make the authorization spec- 
ification task really difficult, and ii) conflicts between 
weak authorizations do not contrast with the require- 
ments of the users specifying the authorizations. 

As we will see in the following section, whenever two 
weak authorizations conflict over a given subject with 
respect to a given access, we consider both authoriza- 
tions to be invalid for the subject. This means that the 
positive authorization cannot be applied and therefore 
the access will be denied to the subject. This policy 
is safe since the access is denied in case of a conflict. 
In Section 7, we will present an approach for solving 
conflicts between weak authorizations. 

4 Access control mechanism 

In this section, we illustrate how, given an ac- 
cess request, the access control mechanism determines 
whether to grant or reject the request. 

An access request is characterized as a triple <u,p,<) 
stating that user u is requesting to exercise privilege p 
on table t. The access request is authorized iff there 
exists a positive authorization for the access that is 
neither overridden not conflicting with respect to u. 
This is formalized by the following definition. 



Definition 5 (Authorized access request) An ac- 
cess request (u,p,t),u 6 U % p G P,t 6 7 1 , is authorized 
iff 3a € AS } n> 0, fia { 6 AS such that u € n s(a),p = 
p(a),t = t(a) t pt(a) = *+ M , and (ai o u a V a,- >„ a). 

Positive authorizations which are overridden or con- 
flicting with other authorizations with respect to the 
user are said to be invalid for the user. 

Suppose a user requests to access a table. If there is 
a positive strong authorization for the required access, 
by Invariant 1, a strong negative authorization cannot 
exist for the same access. Moreover, any weak negative 
authorization for the required access will be overridden 
by the strong authorization. Hence the access must be 
authorized. Analogously,, if there is a strong negative 
authorization for the access, the access must be denied. 
If there are no strong authorizations for the required ac- 
cess, the weak authorizations must be evaluated. The 
access must be authorized if a positive weak authoriza- 
tion exists which is neither overridden nor conflicting 
over u; otherwise, it must be denied. 

We view the access control as a function that, given 
an access request, returns true if the request must 
be authorized and false otherwise. Function • ac- 
cess. controlQ can be expressed as follows. 

( $tT-aulh(u f p,t) if slr.auth(u,p,t) 
access .control (u,p,t) = I jt undecided 

^ wcak-avth(u,p,t) otherwise 

where: 

(true if 3 a strong positive 

authorisation for the 
access 
false if 3 a strong negative 

authorization for the 
access 
undecided otherwiw. 

{true if 3 a positive weak 
authorization for the 
access that is neither 
overridden by nor con- 
flicting with other 
authorizations over u 
false otherwise 

The algorithms implementing functions str~auth() 
and weak.auth() are given in Figures 3 and 4, respec- 
tively. 

The algorithm in Figure 3, implementing function 
str-authQ, works as follows. First, the authorizations 
of the user requiring the access are examined (step 1). 
If any strong authorization is found for the user with 
respect to the access, then the search is terminated. 
Hence, if the authorization is a positive authorization, 
true is returned; otherwise, false is returned. If no 
authorization is specified for the user, then the autho- 
rizations of the groups to which the user belongs are 
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str^autb(u,p,t) 

1. Look for an authorization a 6 AS such that *(a) = u, 
p(a) = p t(a) ~ t, at{a) =strong. 

If such an a is found then go to step 3. 

2. GS := {G } | u 6i Gj for some i > 1}. 

If G5 = 0 then return undecided and exit. 

Look for an authorization d £ AS such that *(a) £ GS, 

p(a) = p,t{a) = t,at(a) = strong. 

If such an authorization is found then go to step 3 

elae return undecided and exit. 

3. If p(o) ="+" then return true else return f alse. 

Figure 3. Algorithm for function strauthO 

evaluated (step 2). If a strong authorization for the 
access is found for any of the groups to which the user 
belongs, the search is terminated. Hence, if the au- 
thorization found is a positive authorization, true is 
returned; otherwise, false is returned. By contrast, 
if no strong authorization is found, undecided is re- 
turned. 

Since weak authorizations may conflict or be over- 
ridden, evaluation of the function wtak-auih() may re- 
quire examination of all authorizations applicable to 
the user through different membership paths connect- 
ing him to all the groups to which he belongs. How- 
ever, it is not necessary to traverse all membership 
paths fully since more specific authorizations override 
less specific authorizations. Thus, first the authoriza- 
tions of the user are considered. Then, the authoriza- 
tions of the groups to which the user belongs are con- 
sidered traversing the membership paths in increasing 
distance. Whenever an authorization is found for a 
group, it is not necessary to proceed further on that 
membership path since cither this authorization over- 
rides those of the groups above it on that membership 
path or these groups are reachable through some other 
membership paths. 

The algorithm implementing function wcak.authQy 
illustrated in Figure 4, works as follows. If the user 
owns a negative authorization for the access, then 
false is returned (step 1) and the algorithm termi- 
nates. Otherwise, if the user owns a positive autho- 
rization, then true is returned (step 2) and the al- 
gorithm terminates. 4 If no authorization for the ac- 
cess is specified for the user, the authorizations of the 
groups to which the user belongs are examined. The 
groups to which the user directly belongs are consid- 
ered in step 3. If any of these groups owns a negative 
authorization for the access, then false is returned 
(step 4) and the algorithm terminates. If not, the sys- 

4 Note that, since weak authorizations may conflict it is impor- 
tant to look first for a negative authorisation and then, only if no 
negative authorisation is found, look for a positive authorization. 



weak_Auth (u ,p,t) 

1. Look for an authorization a € AS such that s(a) = u, 
p(o) = p, t(a) = t t pt(o) ="-', at(a) =»e*k. 

If such an authorization exists then return false and exit. 

2. Look for an authorization a 6 AS such that 

*(a) = u,p(a) = p,t(a) = t,pt(a) = u +",ai(a) =weak. 
If such an authorization exists then return 
true and exit. 

3. Group* ;= {Gj | u €1 Gj} 

4. Look for an authorization a € AS such that 

*(o)e Group*, p(o) = p, t(a) = t, pf(a) ="-", «<{o) =weak. 
If such an authorization exists then return 
false and exit. 

5. A-Grov,p$ := {G k 6 Group* | 3a € AS,s{a) = G fct 
p(o) = p,t(a) = t,pt{a) = "+",at(a) =veak} 

6. N-Grovpi := Group* — 4. Group* 

7. If N.Group* ?t 0 then Group* := {Gj \ 3G 6^-Groups, 
G €i Gj} else go to step 9 

8. If Group* ^ 0 go to step 4 

9. If A-Group$ ^ 0 then return true else return false. 

Figure 4. Algorithm for function weak_auth() 

tern checks whether one of these groups owns a posi- 1 
tive authorization for the access (step 5). If a group 
owns a positive authorization for the access, then it 
is no longer necessary to look at the authorizations of 
other groups along the same membership path. Let 
N -Groups denote the groups for which no authoriza- 
tion has been found. Next, the groups to which any 
group in N .groups directly belongs are considered (step 

7) . If such groups do exist, the process of looking for 
a weak authorization for the access is repeated (step 

8) ; otherwise, the algorithm terminates. A true is re- 
turned if any positive authorization was found during 
the execution; otherwise, false is returned. 

Example 2 Consider the authorization state illus- 
trated in Figure 5, and consider the requests by user 
B to exercise the select privilege on table T. Func- 
tion str-auth(B t 8tl,T) returns undecided and therefore 
function weak-auth(B ,sel t T) is called. This function 
returns false due to the negative authorization of G4 
and hence the access is denied. □ 

5 Administration of authorizations 

The user creating an object is considered the owner 
of the object. As owner, the user can exercise any 
privilege 011 the table and can grant other subjects any 
authorization on the table. Moreover, the owner, can 
also delegate to other subjects the administration of 
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Figure 5. An authorization state 

some privileges on the table. Delegation of adminis- 
tration is enforced through Iwo administrative privi- 
leges: adm- access and administer. The adm-access 
privilege for a privilege on a table allows subjects to 
grant authorizations for the privilege on the table. The 
administer privilege for a privilege on a table allows 
subjects to grant access authorizations and adminis- 
trative privileges for the privilege on the table. We 
do not apply the strong and weak classification on ad- 
ministrative authorizations. Allowing administrative 
authorization to be overridden would raise the prob- 
lem of dealing with authorizations granted by a user 
whose administrative authorizations become overrid- 
den: if the authorizations of the user are not valid, nei- 
ther should the authorizations he granted. This prop- 
agation of the "overriding" effect would make the au- 
thorization administration task unnecessarily compli- 
cated. Therefore, we take the approach that adminis- 
trative authorizations cannot be overridden. To ensure 
this, every time a subject is granted an administrative 
authorization for a privilege on a table, a strong autho- 
rization for the privilege on the table is also granted by 
the system to the subject. Upon deletion of the admin- 
istrative authorizations, this strong authorization will 
also be deleted. 

Although we do not distinguish between adminis- 
trative authorizations themselves as strong and weak, 
we allow users to grant administrative privileges with 
the restriction that only weak authorizations can be 
granted. 

Administrative authorizations are defined us follows. 

Definition 6 (Administrative authorization) 
An administrative authorization a is a 6-titpU 
(s t p f ap,gat t i t g) with s e 5, p £ P, ap € 
{adm-access, administer}, gat £ {strong, weak} ; t € 
T.geU. 

Administrative authorization {s,p t ap,gat,t,g) states 



that subject 5 has administrative privilege ap on ac- 
cess mode p on table i and that this authorization was 
granted by user g. If ^af^seak, s can grant only weak 
authorizations. 

For instance, authorization (4, select, acini-access, 
veak.Ti, B) states that A can grant, and revoke, other 
subjects' weak authorizations for the select privilege on 
table Ti and that this authorization was granted by B . 

Administrative authorizations are summarized in 
Table 1. Note that, since granting an administrative 
authorization to a subject implies granting a strong 
positive authorization to the subject, authorizations for 
the administer privilege must be necessarily strong. 

Note also that subjects holding an administrative 
privilege can grant positive as well as negative autho- 
rizations. This choice is justified by the fact that, since 
negative/positive authorizations can be used to specify 
exceptions to other positive/negative authorizations, 
users allowed to grant permissions should also be able 
to specify negations and vice versa. However, the 
model can be easily extended to the consideration of 
different privileges for the administrations of permis- 
sions and denials by adding the privilege type (-f or 
— ) in the administrative authorization. 

Subjects holding administrative privileges can also 
revoke authorizations. A user can revoke only au- 
thorizations he has granted. Moreover, the autho- 
rizations granted by a user can exist only as far as 
the user has the corresponding administrative privi- 
lege. As a consequence, when a user is revoked the 
administrative authorization for a privilege on a ta- 
ble, a recursive revocation may take place to delete 
the authorizations granted by the user or derived for 
the users on views. Revocation algorithms enforcing 
recursive deletion of authorizations proposed in other 
models [4, 11, 13, 15, 23] can be easily adapted to our 
model. 

6 Ensuring consistency of the autho- 
rization state 

The collection of valid authorizations may change 
upon execution of administrative operations by the 
users. These operations include changes to the autho- 
rization state, the group membership graph, or the ta- 
bles. Operations affecting the authorization state are 
grant and revoke of privileges on tables, operations 
affecting the group membership graph are the addi- 
tion and removal of members from groups, and opera- 
tions affecting the tables are the creation and deletion 
of tables. Although some of these operations do not 
have any effect on the authorizations themselves, they 
may affect the consistency of the authorization state. 
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Administrative authorization 


Semantics 


(s, p, adm-access, strong, t, g) 


3 can grant and revoke weak/strong posi- 
tive/negative access authorizations for p on t 


(s, p, adm- access, weak, t, j) 


s can grant and revoke weak positive/negative ac- 
cess authorizations for p on t 


{s t p, administer , strong, t, g) 


3 can grant and revoke weak/strong posi- 
tive/negative access authorizations for p on t 
s can grant and revoke weak/strong authoriza- 
tions for the administration of p on t 


(s, p, administer, weak, i, </) 


N/A 



Table 1. Administrative authorizations and their semantics 



Hence, every time an administrative operation is re- 
quested, beside the existence of the authorization nec- 
essary for the execution of the request, the consistency 
of the resulting authorization state must be checked. If 
the operation would result in an inconsistent authoriza- 
tion state, its execution must be refused by the system. 

Note that operations that decrease authorizations 
applicable to the subjects (i.e.. revocation of autho- 
rizations, removal of members from groups, or dele- 
tion of tables) do not affect consistency. By contrast, 
operatious increasing the authorizations applicable to 
the subjects may result in an inconsistent authorization 
state and must therefore be controlled. 

Assignment of authorizations to the owner upon cre- 
ation of new tables does not obviously affect consis- 
tency (no authorization may exist on the table before 
it is created), Let us therefore consider the operations 
of granting a new strong authorization and adding a 
new member to a group. 

6.1 Granting of new strong authorizations 

Suppose a user wishes to insert a new strong autho- 
rization a. Inconsistencies may arise if subject s(a), 
any member of s(a) } or any group to which $(a) or any 
of its members belongs, already owns a strong autho- 
rization for privilege p(a) on table t(a) with privilege 
type different from pt(a). 

For instance, consider the authorization state shown 
in Figure 6. Granting a new strong authorization 
{-isel, T3) to G3 would create a conflict with the strong 
authorization (sel, T3) specified for G3. Granting a 
new strong authorization (sel, Tj) to G3 would create 
a conflict with respect to subject G$ and all its mem- 
bers with strong authorization {-«sel, T 2 ) specified for 
G2. Granting a new strong authorization (sel, T 4 ) to 
Ga would create a conflict with respect to user A, with 
the strong authorizations (-»sel, T4) specified for A. 



Gi (-sel.T!) 
G 2 <-sel,T a > 




Figure 6. An authorization state 

Moreover, it would create a conflict, with respect to 
subject G5 and all its members with strong authoriza-. 
tion (-isel, T 4 ) specified for G5. 

Figure 7 illustrates an algorithm for determining 
whether the addition of a new authorization would re- 
sult in an inconsistent authorization state. The algo- 
rithm returns ok if the resulting authorization state 
is consistent; it returns the conflicts which would arise 
otherwise. If there is a conflict between the new autho- 
rization and another authorization with respect to sub- 
ject $ only because of the membership of s to another 
subject s' with respect to which the two authoriza- 
tions conflict, then only the conflict over subject s* is 
returned. Conflicts which are implied by other conflicts 
are not returned for sake of simplicity (it is sufficient 
to communicate to the user the conflict which implies 
the other ones). For example, with reference to Figure 
6, if authorization (sel, T 4 ) is being granted to £3, 
the conflict with the negative authorisation specified 
for subject G5 with respect subject G& is returned. Al- 
though these authorizations also conflict with respect 
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to all members of G5 (viz., B and (7), these conflicts 
are not returned. 



Check ^autbo(a) 

1. Anc 1- {s e S \ 3u > l,tf(a) €n '} 

2. Desc := {s € 5 | 3n > 0,s €n 

3. /4nc_i?eic :={»6CJ- (Anc U Dcsc) \ 3n > 1, j t g £>ejc : 
*i 6n *) 

4. Confl-Anc := {a; £ AS | *(a;) € Anc,p(a,) = p(a), f(ai) = 
t(a),pt(a,) 5* pt(a),at(a,-) - strong} 

5. Conji.Dr.ac i- {a, 6 AS | 5(0.) 6 Dcsc,p(ai) = p(a), 
i(aj) = t{a),pt(a % ) # pt(a), at( ai ) = strong} 

6. Confi-AD 1- {ai € AS | *{o,-) 6 Xne./)»£,p(a,-) = 
p(a),t(a;) = t(a),pt(«i) ?£ pi(a),a<(a;) s: strong} 

7. If Ct?n/J_AndjCon/I-£>ejc U ConjLAD-= 0 then return oX 
aud exit 

8. For each a; €Conjl-Anc do return "conflict: a o,( a ) o," 
end for 

9. For each a, € ConfiJ)e$c do return "conflict: a 0 f ( O{ ) ai" 
endfor 

10. For each a, € ConJLAD do 

Con/T(o ( ) := {s € S | 3n,m > 0, s £ n 5(a),5 €m 
Disj-Confl(ai) := {3 eCon/lfa;) | 3mp 6 (A/P(a,4(a)) 

uMP(*,*(ai))). * *, *' eConft{ ai ),s' £ mp} 

For each s € Disj-Confi[ai) do return "conflict: 00,0," 
endfor 

endfor. 

Figure 7. Evaluation of the consistency of the 
authorization state resulting from addition of 
authorization a 

The algorithm in Figure 7 works as follows. Sup- 
pose the addition of a new strong authorization a is 
required. In step 1, set Anc consisting of all subjects 
(groups) to which subject $(a) belongs is determined. 
In step 2, set Desc consisting of all subjects which be- 
long to s(a), including s(a) itself, is determined. In 
step 3, set Anc-Dcsc consisting of all groups (not al- 
ready in Anc or in Dcsc) to which any of the mem- 
bers of s(a) t or s(a) itself, belongs is determined. In 
step 4, set Confl-Anc of strong authorizations spec- 
ified for any group in Anc with same privilege and 
table as authorization a being granted but with dif- 
ferent privilege type is determined. Analogously, in 
step 5 and 6, sets Confl-Desc and Confl-AD of strong 
authorizations specified for any subject in Desc and 
in AncJ)esc, respectively, with same privilege and ta- 
ble as authorization a being granted but with differ- 
ent privilege type arc determined. If all three sets, 
Confl-Anc % Confl-Desc, and Confl-AD } are empty, a 
conflict is not found and ok is returned (step 7). Oth- 
erwise, conflicts which would have been introduced if 
authorization a were inserted are returned as follows. 



In step 8, the conflicts between authorization a being 
inserted and every authorization a, 6 Confl-Anc with 
respect to subject s(a) for which the authorization is 
being inserted is returned. In step 9, the conflict be- 
tween authorization a being inserted and every autho- 
rization Of € Confl-Desc with respect to subject s(a,*) 
of the considered conflicting authorization is returned. 
Finally, in step 10 the conflicting authorizations spec- 
ified for other groups to which the members of s(a) 
belongs are considered. To avoid returning a conflict 
with respect to a subject which belongs to s(a) and 
s(dj) only because of its membership of another sub- 
ject for which the conflict is also returned, the following 
process is used. For each authorization a,- £ Confix AD, 
set Confl(ai) of all the subjects with respect to which a,- 
conflicts with a, i.e., all subjects belonging to both s(a) 
and s(di) t is determined. Then set Disj-Confl(ai) of all 
subjects in Confl(<Xi) for which there exists a member- 
ship path to s(a) or to $(a ( ) which does not contain 
any other subject in Conflfa) is determined. Finally, 
for each subject s £ Disj-Confl(ai) y the conflict of au- 
thorization a being inserted with authorization a, , with 
respect to subject s, is returned. 

To illustrate how the algorithm works, let us con- 
sider the following example. In the following a, it de- 
notes an authorization (either positive or negative) of 
subject s on table t 

Example 3 Consider the authorization state illus- 
trated in Figure 6 and suppose that a new strong pos- 
itive authorization for the select privilege on table Ti 
is being granted to group G3. The algorithm works as 
follows: 

1. Anc := {G^,G■l} 

2. Desc := [G- ii G< 1 G'»A,B,C) 

3. AncDesc := {G 6 } 

4. Confl-Anc := {ao^Ti} 

5. Confl-Desc := {ao 4 ,Ti} 

6. Confl-AD := {a^rj 

7. {aCi.Tr ,aa 4t Ti .aGa.r, } ^ 0 continue 

8. return "conflict: ac7 3 ,7\ <>a B flGi,Ti " 

9. return "conflict: a<7 3 ,r t <>g 4 0<7«,7\" 
10. ConfUaotPi) •= {G bi B>C} 

Disj-Confliac^T,) := {G^C} 
return "conflict: aa if Ti oa 5 aa 9 ,Ti n 
return "conflict: ao 3 ,T t °C <*Gi,T x n > 

62 Addition of new members to groups 

Consider the addition of a member m to a group 
Gk • Inconsistencies may arise if subject m, any of its 
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G 7 (sel.Tj) 



(sel,T 3 ) G 3 G 4 (-sel.Tj) 



A <-scl,T 2 > 

Figure 8. An authorization state 

members, or any of the groups to which m itself or 
any of m's members belong, owns some authorization 
which conflicts with an authorization owned by group 
Gk or by any of the groups to which Gt belongs. 

For instance, consider the addition of group G3 as a 
member of group G2 in the authorization state shown 
in Figure 8. This operation would introduce the fol- 
lowing conflicts: 

• Authorization (sel, Ti) of G\ would conflict, with 
respect to user A, with authorization (isel, Ti) 
owned by G4. Formally: aG lt Ti <>a a G %t T x > 

• Authorization (sel, T2) of G2 would conflict, with 
respect to user A t with authorization (-»sel, Tj) 
owned by A. Formally: a<j 3p T 3 <>A &a>t 2 - 

• Authorization (^sel, T 3 ) of G\ would conflict, 
with respect to G3 and A, with authorization {sel, 
T 3 ) owned by G 3 . Formally: aG u Ti<>Q*<*Gs,Ti and 

fl Gi,T 3 <>A fGs.Ts- 

Figure 9 illustrates an algorithm for determining 
whether the addition of a member to a group would 
result in an inconsistent authorization state. The al- 
gorithm returns ok if the resulting authorization state 
is consistent; it returns the conflicts which would arise 
otherwise. Note that, again, for sake of simplicity, con- 
flicts which are implied by other conflicts are not re- 
turned, that is, if there would be a conflict between 
two authorizations with respect to subject $ only be- 
cause of the membership of s to another subject s' with 
respect to which the two authorizations conflict, then 
only the conflict with respect to subject s f is returned. 

The algorithm in Figure 9 works as follows. Con- 
sider the addition of member m to group Gk « In step 
1, a check is made to determine whether m is already 
a member, either direct or indirect, of G*. 5 If m is 

5 Not* that a subject can belong to a group through different 
membership pat lis. 



1. If 3n > 1 euch that m €n G k then return ok 

2. Anc := (a e G | 3n > 0, G k €n * and /9i > 0,m Gi s) 

3. Disj-Dcsc := {a 6 G | 3n > 0, j G„ m and /9t > 0,3 €, 
G k ) 

4. Anc.Disj-Dtsc := {* € G - (DisjJ^csc U Anc) \ 
Bn> l t si 6 Disj-Dcsc : j, Gn 

5. Confl-DtAc := {(ai,a,j) € AS | *(a;) € Disj-Dtsc y 

s[aj) G Anctp(ai) - p(aj),t(a;) = *(a>) ( p((a t ) £ 
pt(aj),at(ai) = at(aj) = strong) 

6. Confl-AD := {(ai,aj> G AS \ »(a;) G Anc.Disj-Desc, 
s(o ; ) G Anc,p(oi) = p(a,-). «(<*•) = t(ay),pi(ai) # 
pt(aj),at[ai) = at(aj) = strong) 

7. If Confl-Dcsc U ConJLAD = 0 then return ok and exit 

8. For each G ConfLDcsc do 
return "conflict: o t - o,( 0i ) a/' endfor 

9. For each (a»,ay) 6 ConJLAD do 

Con/ifai.ay) ;= {* | « Gn m,3 Gn 
Duj-Con/I^ay) := {s G CWI(ai,aj) | 
3m P G (MP(s, m) U A/P(« t afa,))), 

For each a G Di*j-Gonfi(ai,aj) do 
return "conflict: a; o, ay" 
eadfor 

endfor. 

Figure 9. Evaluation of the consistency of the 
authorization state resulting from addition of 
member m to group G k 



already a member of G*, then no inconsistencies can 
arise by the execution of the operation and ok is re- 
turned. Otherwise, the algorithm continues to execute. 
In step 2, set Anc of all the groups to which group 
Gk belongs (including G* itself), and to which m does 
not belong, is determined. In step 3, set Disj-Dcsc of 
all the subjects which belong to m (including m it- 
self) and do not belong to Gk is determined. Then, 
in step 4, set AncDisj-Desc of all the groups (not al- 
ready in DisjJ)tst or in Anc) to which any of the sub- 
jects in Disj-Dcsc belongs is determined. In step 5, set 
Confl-Desc of all pairs of strong authorizations with 
the same privilege and table but with different priv- 
ilege type such that the subject of one of them is in 
Disj-Dcsc and the subject of the other is in Anc is de- 
termined. In step 6, set Confl-AD of all pairs of strong 
authorizations with the same privilege and tabic but 
with different privilege type such that the subject of 
one of them is in Anc-Disj-Desc and the subject of the 
other one is in Anc is determined. If sets Confl-Dcsc 
and Confl-AD are empty, no pair of conflicting autho- 
rizations exists, and hence ok is returned (step 7). Oth- 
erwise, the conflicts which would arise are returned as 
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Figure 10. An authorization state 

follows. In step 8. the conflict between every pair of 
authorizations, (a,-, ay) in Confl.Desc with respect to 
subject ${di)> which is a member of m, is returned. Fi- 
nally, in step 9, every pair of authorizations (a,-, ay) in 
Confl-AD 'ia examined. Then, to avoid returning a con- 
flict with respect to a subject which belongs to s(ai) 
and m (and therefore would indirectly belong to s(ay)) 
only because of his membership of another subject for 
which the conflict is also returned, the following pro- 
cess is followed. For each pair (a*, ay) 6 Confl^AD, set 
Confl(ai t ay) of all the subjects with respect to which a,* 
would conflict with ay, i.e., all subjects which belong 
to both s(di) and m is determined. Then, set Disj- 
Confl(ai i aj) of all subjects in Confl(a it aj) for which 
there exists a membership path to s(oi) or to m which 
does not contain any other subject in Confl(ai,ai) is 
determined. For each of subject 5 € Di$j-Confl(ai, aj), 
the conflict between authorizations a; and ay with re- 
spect to subject s is returned. 

Example 4 Consider the authorization state illus- 
trated in Figure 10. Suppose a request is submit- 
ted to the system requiring the addition of group 
Ga as a member of group GY The execution of 
Check .member (G^Ga) returns the following conflicts: 

"Gi.Ta 0<7» iGi.Tj and flc 5( Ti °C7t i,Ti * a 



7 Resolving conflicts among weak au- 
thorizations 

Our model allows the simultaneous presence of con- 
flicting weak authorizations. Hence, the authorization 
state may contain two weak authorizations, one stating 
that an access should be granted to some subject, and 



the other one stating that the access should be denied 
to the subject. The way we solve this dilemma is by 
adopting a safe policy from a security viewpoint and 
denying access. 

In this section, we show that using the default of 
denial is not the only option for resolving conflicts be- 
tween weak authorizations. Users can resolve conflicts 
by inserting additional authorizations in the authoriza- 
tion state. This means that the users do not have to 
accept the system default option if they do not want; 
they can also eliminate conflicts in ways that best suit 
their needs. This is expressed by the following defini- 
tion. 

Definition 7 (Resolution of conflicts) A conflict 
between two weak authorizations a{ and ay with respect 
to subject s has a resolution iff it is possible to specify 
an authorization overriding one of these (with respect 
to subject s). 

For example, consider the authorization state shown 
in Figure 5. The authorizations specified for groups Ga 
and G5 conflict over user B. The conflict can be re- 
solved by specifying an additional authorization, either 
positive or negative, for D. 

We claim that every conflict, with one exception, 
can be resolved by the addition of a new authorization. 
The exception occurs when conflicting authorizations 
are specified for the same subject. 

To see this, suppose that there exist two authoriza- 
tions a t a:nd ay for a privilege on a table that conflict 
with respect to a subject s. Thus, p(a,) = p(ay) and 
i(a t ) = t(a ; ), but p<(a t ) ^ pt(aj). There are three 
cases to consider. 

Case 1: s(a{) / s(ay). 

Clearly, s / s(a,) and s ^ s(<*j) (since otherwise a,- 
and ay will not conflict with respect to s). The conflict 
between Oj and ay with respect to subject $ can be 
resolved by inserting another authorization a m with 
p( a m) = p(ai),t(a m ) = *(a,'),/?(a m ) = *, and either 
pt(<*m) = H- or pt(a m ) = depending on whether the 
grantor wishes to give or deny the privilege to s. 

Case 2: s(a t ) = s(ay), but s ^ s(a;) 

The conflict can once again be resolved by inserting 
another authorization a m as given in case 1 above. 

Case 3: s(a,) — s(a ; ) = s 

In this case, the conflict can only be solved by ei- 
ther deleting one of the two authorizations or inserting 
a strong authorization a with s as subject and same 
privilege and table as the two conflicting authoriza- 
tions. Note, however, that the insertion of the strong 
authorization may not always be possible, since it may 
result in an inconsistent authorization state. We claim 
that it is proper in this case to require that one of the 
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two authorizations be deleted in order to resolve the 
conflict since the simultaneous presence of a negative 
and a positive authorization specified for Gi is intrin- 
sically ambiguous. 

Note that conflicts between weak authorizations 
may arise when any of the administrative operations 
are executed. In particular, operations that decrease 
the authorizations of subjects, such as removal of users 
from groups and revocation of authorizations, may gen- 
erate new conflicts. 

8 The mediator 

In this section, we illustrate how the mediator is 
used to mirror different protection policies. In partic- 
ular, we show that the following policies can be ex- 
pressed in our system: the traditional closed and open 
policies, the closed policy with negation and the en- 
forcement of the denials-take-precedence principle, and 
the closed policy with negation and the enforcement of 
the most specific authorization takes precedence prin- 
ciple. Note that the last policy is the one actually en- 
forced by the model implemented by our mechanism. 
The first three policies can be supported by using only 
some of the features that our model provides. 

The implementation of a classical closed policy is 
straightforward in our model. It is the task of the me- 
diator to ensure that only positive authorizations can 
be specified; the mediator rejects any attempts by the 
users to specify negative authorizations. 

For the open policy, the mediator must ensure that 
the following conditions exist: For. every object, a 
weak positive authorization is specified for the group 
representing the root of the graph. 6 Users will then 
be allowed to specify only strong negative authoriza- 
tions. Since a strong negative authorization overrides 
the weak positive authorization in our model, the result 
is an open policy where all accesses for which users do 
not specify negative authorizations are allowed. Note 
that current DBMSs have a group, called public, con- 
taining all users of the system, to which authorizations 
can be granted; however, since negative authorizations 
are not supported, no exceptions to the authorizations 
granted to the group public can be enforced. 

The denials-take-preccdence policy can be imple- 
mented by the mediator by ensuring that all positive 
authorizations are weak and all negative authorizations 
are strong so that negative authorizations will always 
override positive authorizations. 

As stated earlier, a major advantage of using our 
framework is that all users are not constrained to the 

6 If the membership graph ia not single rooted, a group, called 
public, containing all subjects in the system can be inserted. 




Figure 11. An example of group membership 
graph 



use of a single policy. They can choose to apply differ- 
ent policies on different relations, as shown in the fol- 
lowing example. Suppose the group membership graph 
is as given in Figure 11 and suppose Henry creates the 
following tables with their different protection require- 
ments: 

• Public -info: Everybody is to be allowed access. 
This can be accomplished by granting a strong 
positive authorization to Users. 

• Hat .pub-info: Everybody who is a citizen has 
access. A weak positive authorization can be 
granted to Users and a strong negative authoriza- 
tion granted to Hon-citixens. 

• Reports: Everybody can access unless explicitly 
denied. A weak positive authorization is granted 
to Users. Negations can be specified at any time. 

• Organization-info: Henry wishes to retain con- 
trol of all access authorizations on the relation ex- 
cept for the select privilege which can be admin- 
istered by the members of the group Staff. More- 
over, Henry does not want Gary to be able to read 
information in the relation. To this end, Henry 
grants the weak adm-a.ee ess for the select privi- 
lege on the relation to St af f and grants a negative 
strong authorization for the select privilege on the 
relation to Gary. 

• Projects: Projects contains information about 
software projects. People involved in software de- 
velopment should be authorized. A weak positive 
authorizations is specified for Soft-developers. 

• Projects: Projects temporarily contains some 
private information that is not to be released for 
some time. Consultants must be temporarily for- 
bidden access to the relation. A negative (strong 
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or weak) authorization can be specified for the 
select privilege on the relation for Consultants. 
There is ao need to revoke the authorization previ- 
ously granted since it will once again become valid 
upon revocation of the denial. D 

9 Related Work 

Early authorization models [8] were based on the 
closed world policy and accordingly only allowed the 
specification of positive authorizations. More recent 
authorization models also permit specification of neg- 
ative authorizations stating accesses to be denied. In 
some of these models, conflicts are solved simply by 
adopting the denials- take-precedence policy [4, 17, 14, 
21]. Other models provide more sophisticated conflict 
resolution policies [18, 19 ( 7, 22). 

The concept of strong and weak authorizations 
adopted in our model has been first introduced in the 
authorization model of Orion [19]. In this model, au- 
thorizations can be specified only for groups of users 
(called roles in Orion), not for single users. Posi- 
tive authorizations granted to a group propagate to 
all the members of the group. Negative authorizations 
granted to a group propagate to all the groups to which 
it belongs. Resolution of conflicts is based on the con- 
cept of more specific authorization. The Orion autho- 
rization model has the merit of having introduced the 
concept of strong and weak authorizations. However, it 
suffers from several limitations, which we have tried to 
overcome in our model. First, in the Orion authoriza- 
tion model, negative authorizations propagate from a 
subject to the groups to which the subject belongs (not 
vice versa like in our model). This means that it is not 
possible to grant a negative authorization to a group 
which holds for all the members of the group. Second, 
in the Orion authorization model, authorizations can- 
not be granted to single users. Moreover, users are not 
taken into consideration when evaluating the consis- 
tency of the authorization state; a user can belong to 
groups holding conflicting authorizations. Since a user 
is permitted an access if he belongs to a group that 
has a positive authorization for it, in this case, access 
is authorized. Then, it is not possible to really enforce 
strong authorizations at the level of single users. Third, 
the Orion authorization model requires the authoriza- 
tion state to be complete, i.e., for every possible ac- 
cess an authorization, either positive or negative, must 
exist. This approach forces the use of negative autho- 
rizations to represent cases where the authorization is 
simply not to be given and makes the authorization 
administration task very difficult. Fourth, the Orion 
authorization model does not provide any administra- 



tive policy: every user authorized for an access can also 
grant authorizations for that access. This approach 
raises several problems. In particular, it is impossible 
for the owner of an object to retain control of the users 
that can access his objects. 

With nispect to multipolicy models, Jonscher and 
Dittrich [17] present an access control system for 
the protection of information in distributed federated 
database systems which allow the enforcement of dif- 
ferent policies. Each policy is characterized by 19 at- 
tributes referring to different policy aspects (e.g., types 
of privileges allowed, signs of authorizations allowed, 
subjects' hierarchies to be considered). Different refer- 
ence monitors are then defined, each enforcing a par- 
ticular policy. The behavior of each access monitor 
is determined by the attributes specified for the pol- 
icy implemented by the monitor. Each access request 
submitted to the system is forwarded to the responsi- 
ble reference monitor for the object to be accessed and 
allowed or denied accordingly. 

Other work on multipolicy aspects concerns the inte- 
gration and coexistence of different , possibly inconsis- 
tent, policies [10]. Indeed, where different systems ap- 
plying different policies interact, the problem of which 
policy to apply with respect to the common process 
arises. Hosmer [16] describes a multipolicy paradigm 
for supporting the enforcement of different protection 
policies. The approach is based on the concept of 
metapolicy that is a policy about policies. A concep- 
tual model of this "multipolicy machine" has been pro- 
posed by Bell [2]. The model provides a formal frame- 
work for dealing with the combination of unspecified 
policies. 

10 Conclusions 

The usefulness of separating security policies from 
security mechanisms in the development of access con- 
trol systems has long been recognized [12, 9]. Security 
policies are high-level guidelines specifying how access 
is to be controlled. Mechanisms are sets of functions 
implementing protection policies. Among the advan- 
tages of this separation is that it is possible to change 
the policy without requiring changes to the underlying 
mechanism [9], In spite of the policy- mechanism sepa- 
ration principle, access control systems today are based 
on a mechanisms enforcing a specific set of predefined 
policies. 

In this paper, we have moved a step toward the de- 
velopment of a flexible access control mechanism that 
can support different policies. In particular, we have 
presented an authorization model on which Buch a flex- 
ible mechanism can be based. The model permit** both 
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positive and negative authorizations, permits autho- 
rizations that must be strongly obeyed and authoriza- 
tions that allow for exceptions, and enforces ownership 
together with delegation of administrative privileges. 
The flexibility of the model makes it possible to rep- 
resent different policies. We have presented the model 
and illustrated how it can be used to express different 
policies and different protection requirements. 

Our proposal represents only an initial step in 
the development of multipolicy mechanisms and much 
work still needs to be done. Issues that we plan to in- 
vestigate include the identification of different policies 
with respect to which users can tailor the system; the 
definition of the mapping functions between the poli- 
cies and the reference authorization model; the ability 
to support unspecified policies; the regulation of the co- 
existence of multiple, possibly conflicting, policies on 
the same object; and the efficient implementation of 
the mechanism. 
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